---
title: "Scrolling Performance"
---

The grid is fast. However, the grid can also be configured and extended in many ways. This page explains how you can make the grid go faster.

{% if isFramework("react") %}
{% warning %}
React in Production Mode works faster than Dev Mode. Given the DOM complexity of the grid, React Production Mode will
allow the grid to perform optimally without any overhead introduced by Dev Mode. Performance testing should be
performed in Production Mode only.
{% /warning %}
{% /if %}

## Setting Expectations

The grid can be as fast as demonstrated in the [Demo](/example). You can resize the demo application to the same size as the grid in your
application by resizing the browser, then navigate around the grid (scroll, filter, etc.) and see how fast the demo grid is compared to your
own implementation. If the demo grid is going faster, then there is room for performance improvements.

## Check Cell Renderers

The grid can be slowed down by custom [Cell Renderers](./component-cell-renderer/). To test this, remove all Cell Renderers from the grid and
compare the speed again. If the grid does improve its speed by removing Cell Renderers, introduce the Cell Renderers one by one to find out
which ones are adding the most overhead.

## Defer Slow Cell Renderers

If a cell renderer is identified as slow then it can be marked for deferred rendering. This is achieved by setting `deferRender: true` on its `cellRendererParams`. The grid will display a skeleton loading cell in place of the cell renderer until the user has stopped scrolling. This improves scrolling performance by not blocking the main thread with expensive calls to the real cell renderer.

For more details see: [Defer Slow Cell Components](./component-cell-renderer/#defer-slow-cell-components).

{% if isFramework("angular") %}

## Consider JavaScript Cell Renderers

If deferring a cell renderer is not appropriate then it is worth noting that the grid uses AG Grid's own internal rendering engine which does not use Angular. As such, each time an Angular Cell Renderer is used,
the grid switches context into an Angular application. This context switching can be time consuming when done multiple times (i.e. each cell).

Consider using JavaScript Cell Renderers instead of Angular Cell Renderers to see if it makes your rendering faster.

## Optimising Angular Cell Renderers

If you are using Angular Components as Cell Renderers, consider using [OnPush](https://angular.dev/api/core/ChangeDetectionStrategy) change detection strategy. This is recommend by Angular as outlined in their docs: [Best Practices > Performance](https://angular.dev/best-practices/skipping-subtrees).

{% note %}
Angular supports coalescing of multiple change detection cycles into a single cycle which can lead to significant performance improvements. This can be achieved via `provideZoneChangeDetection` as described [here](./angular-ngzone/#recommended-ngzoneoptions).
{% /note %}

{% /if %}

{% if isFramework("vue") %}

## Consider JavaScript Cell Renderers

If deferring a cell renderer is not appropriate then it is worth noting that the grid uses AG Grid's own internal rendering engine which does not use Vue. As such, each time a Vue Cell Renderer is used, the grid
switches context into a Vue application. This context switching can be time consuming when done multiple times (i.e. each cell).

Consider using JavaScript Cell Renderers instead of Vue Cell Renderers to see if it makes your rendering faster.
{% /if %}

## If Possible, Avoid Cell Renderers

Cell Renders result in more DOM. More DOM means more CPU processing to render, regardless of what JavaScript / Framework is used to generate the DOM.

Ask the question, do you really need the Cell Renderer?

If you are only manipulating the value rather than creating complex DOM, would a [Value Getter](./value-getters/) or [Value Formatter](./value-formatters/)
achieve what you want instead? Value Getters and Value Formatters do not result in more DOM.

## Avoid Auto Height

[Auto Height Rows](./row-height/#auto-row-height) is a great feature that we love. However it also creates more complex DOM inside each Cell.

If you are looking for ways to squeeze performance, consider turning this feature off. As with all suggestions here, it is paramount you profile
your own application with this suggestion to see how much of a difference it makes and if the trade off is worth it for your application.

## Configure Row Buffer

The `rowBuffer` property sets the number of rows the grid renders outside of the viewable area. The default is 10. For example, if your
grid is showing 50 rows (as that's all that fits on your screen without scrolling), then the grid will actually render 70 in total (10 extra
above and 10 extra below). Then when you scroll, the grid will already have 10 rows ready and waiting to show, so the user will not see a redraw
(not all browsers show the redraw, only the slower ones).

Setting a low row buffer will make initial draws of the grid faster (e.g. when data is first loaded, or after filtering, grouping, etc.).
Setting a high row buffer will reduce the redraw visible vertically scrolling.

## Debounce Vertical Scroll

By default, there is no debouncing of the vertical scroll. However, in some rare circumstances, you may wish to debounce the vertical scroll
so that the grid only scrolls after the user has finished updating the scroll position.

To debounce the vertical scroll, set grid property `debounceVerticalScrollbar=true`.

## Disable Row Highlighting

By default, rows are highlighted as the mouse hovers over them. As [Row Highlighting](./row-styles/#highlighting-rows-and-columns) works by the grid
adding the CSS class `ag-row-hover` to each row getting hovered you may see an increase in scrolling performance by disabling this.

To disable row highlighting, set the grid property `suppressRowHoverHighlight=true`
